@kjm said in File system problems & solutions: the windows version of this CLI The CLI program should probably just be the same .exe file which is also the graphical thing. According to [1], its default location might be c:\Program Files (x86)\Pycom\Pycom Firmware Update\pycom-fwtool-cli.exe. [1] https://community.hiveeyes.org/t/setup-commandline-based-micropython-development-environment-on-linux-macos-and-windows/1639/15

Could you simply feed the WDT while you write until you flush?

@paul-thornton Look like a great tool to use

@robert-hh I was thinking about that however I am not aware of a straightforward way how individual parameters could be updated by the application. The script would be frozen anyway. I was also thinking to move all parameters to NVS however the config also contains few strings which are not directly supported by the NVS right now. I think that the best solution will be to put default parameter values into Python script which will be frozen during build process. After boot it will be tested if NVS contains "init" flag and if not an initialization method will be called. Within this method individual parameters will be loaded from Python script to a dictionary which will then be dumped into json file stored in the internal file system. This will happen only during first boot after last firmware flashing.

You can get a list of files with uos.listdir(<dir>). If you tell the version by the modification data, uos.stat()[7] tells you the file modification time, given that the clock was set appropriately, and machine.reset() can be called to reset the device. If you do not have RTC supplied by a battery, you can set the time via ntp by: from machine import RTC rtc=RTC() rtc.ntp_sync("pool.ntp.org") Then, the file modification times are valid. If you use another mechanism as version indicator, like the name of a file or the content of a file, you have to define and implement it yourself.

@dbrgn The library may also have a local cache, which would be used for reading, and could compare values against the cache before actually writing to flash. There could also be some way to write only a few bytes rather than full sectors like a filesystem would do, not sure if that's actually possible with the flash interface used.